            *      *               *     *                    *
            **     *               **   **                    *
            * *    *          *    * * * *        *       *   *
            *  *   *   ***  *****  *  *  *   ***  ****  ***** ****
            *   *  *  *   *   *    *     *  *   * *   *   *   *   *
            *    * *  *****   *    *     *  *   * *   *   *   *   *
            *     **  *       *    *     *  *   * *   *   *   *   *
            *      *   ****   *    *     *   ***  *   *   *   *   *
            *                                                     *
            *    A monthly guide to BITNET servers and services   *
            *******************************************************

                     Volume 1  Number 3  -  September 1986

                     Editor:  Chris Condon  BITLIB@YALEVMX

            Bitnotes ............................................ 1
            The Proposed BITNET Charter ......................... 2
            Announcing COMSERVE ................................  4
            New Mailing Lists ................................... 7
            The Hewlett Packard Public Networking Newsletter .... 9
            CYBSERV ............................................ 10
            Coming Soon: GRAND ................................. 11
            More New LITSERVs .................................. 11
            The RELAY Rules .................................... 13
            Feedback ........................................... 16
            NetMonth Policies .................................. 17

            _______-----___--______________________________________
            ____------------------_________________________________
            _-----__-----------------______________________________
            ---____----__---_----_-----____________=======_________
            -_____---___----_----___----________=============______
            ______-____----____--_____---______===============_____
            _________----________-_______-_____===============_____
            _______----_________________________=============______
            ______----_____________________________=======_________
            ____----_______________________________________________
            __-----________________________________________________
            ------_________________________________________________
            ---------_________________________________________-----
            -----------------____________________------------------

            A complete  list of servers  and services is  available
            from any  NETSERV file server as the  file named BITNET
            SERVERS.  News,  article submissions,  additions to the
            list of servers and services, subscription requests and
            letters to the editor should be sent to BITLIB@YALEVMX.
            Subscribers  are  also  sent  BITNET  SERVERS  updates.

            Printing this file:  VM users  can print  this magazine
            by first copying or renaming it to NETMONTH LISTING and
            then printing it with your local file printing command.

            -------------------------------------------------------

            FuzzyBytes Electronic Publishing  "Because We're Here."
1

                                                                       Page 1


   *************************************************************************
  * Bitnotes                                                        Issue 3 *
  ***************************************************************************

                 If "everybody knows" such-and-such, then it
                 ain't so,  by at least ten thousand to one.
                                     - Robert A. Heinlein

   Everybody  knows about  the new  Relay rules, right?  And everybody  knows
   about  the proposed  BITNET  Charter.  Hmmmph!  Probobly not.  Many of the
   more  informed  readers out  there  are  aware  of these  things,  and  my
   apologies  to you.  As  for the  rest of you,  I have taken the liberty of
   including  both  documents  in this  issue of  NetMonth  for your perusal.
   But before  we go  any further,  I want to stress that these documents are
   not (shall I  repeat  that?) NOT in  their final  forms.  They  are  still
   subject  to intelligent  debate  and  modification.  However,  they should
   prove to be interesting reading.

   The new  Relay rules:  I  find them  to be pretty reasonable.  They strike
   a fair  balance  between  what Relay is  generally  used for  (recreation)
   and network  load.  The  additional  user class  (for channels  above 999)
   is good way to  highlight Relay's educational possibilities as well.   The
   usage guidelines are well drawn out and nobody  should have  any  problems
   following them.  Best  of all, it gioves the  Relay Operators the power to
   enforce them.

   The BITNET Charter:  This will  probobly  be subject  to a lot  of  change
   before  the year  is out.  There  are a few  provisions  missing yet (like
   requiring  the Executive Committee to print the minutes of it's  meetings,
   which it does anyway) but those changes are probobly being  written as you
   read  this.   Most  of  all there  has  been  a lot  of  debate  over  the
   possibility of annual BITNET membership fees (for the node,  not the user)
   which hasn't been entirely settled.  Stay tuned for the final solution.

   On  the lighter  side,  we have  TWO new servers, COMSERVE and CYBSERV.  I
   must say that COMSERVE is the first file server I have used that is easier
   to use  WITH the  user  interface  exec than  without.  Unfortunately  VAX
   users  will have  to do  without  it.  CYBSERV,  a mail based file server,
   will  provide  some  much  needed  support  for people  using Control Data
   Corporation Cyber computers. (Cyber sites cannot send interective messages
   so they miss a lot of the avialable BITNET services.

   Also among the good news are some more revised LISTSERVS, a preview of the
   GRAND servers,  and an  electronic  magazine for  HP3000  users (all three
   of  you).  Somewhere in here is the usual article about new mailing lists.
   Of  course, you'll find the Feedback letters column at the tail end of the
   magazine.

   Enough of this.  Read on...

                             Virtually,

                                   Chris
1

                                                                       Page 2


   *************************************************************************
  * The Proposed BITNET Charter                                             *
  ***************************************************************************

                                               The BITNET Executive Committee
                                                          Post Office Box 364
                                                  Princeton, New Jersey 08540
                                                            (EXCMTE-L@BITNIC)

                             BITNET CHARTER

                              July 23, 1986

                               Edition 1.4

  Purpose

  BITNET  is chartered  by its  Class A and  B member  institutions  for  the
  purpose  of facilitating  non-commercial exchange of information consistent
  with the academic purposes of its Class A and B members.

  History

  BITNET, which  originated in  1981 with a  link between CUNY and Yale, grew
  rapidly  during the next  few years,  with management  and systems services
  provided on  a volunteer  basis  largely  from CUNY  and Yale. In 1984, the
  BITNET  Directors  established  an  Executive  Committee  to provide policy
  guidance.

  Funding from  IBM in  1984 to  EDUCOM and CUNY for a BITNET Network Support
  Center  provided  formalized  information,  management, and system services
  for BITNET.  At the  end of  1986 this  funding  will end,  and alternative
  sources of support for these activities will be needed.

  Membership

  There are four classes of membership:

  Class A members     degree-granting institutions of higher education

  Class B members     certain  consortia and  affiliates  of  institutions of
                      higher education

  Class C members     certain non-profit organizations

  Class D members     certain other organizations

  These  and other  membership  rules may  be modified  and promulgated  from
  time to time by the Executive Committee.
1

                                                                       Page 3


  Membership Representatives

  Each member institution  or organization  will  designate 3 representatives
  as follows:

  1.  Institutional BITNET Director--official representative to BITNET.

  2.  Technical Representative--an individual appointed by the  Institutional
      BITNET  Director  who can  speak  for the  status of  all the computers
      connected to BITNET at that institution.

  3.  Information  Services  Representative--an  individual  appointed by the
      Institutional  BITNET  Director  who is  responsible for  disseminating
      information  about BITNET  to end-users  of each  BITNET  node  at  the
      institution.

  Executive Committee

  All responsibility  for policy,  business, and  technical affairs of BITNET
  is vested  in the Executive  Committee which  consists of eleven Class A or
  Class  B Institutional  BITNET Directors  plus  non-voting  representatives
  from other major academic networks, as invited.

  The Executive  Committee will  hold an  annual meeting  within three months
  following  the annual  election,  and at any place designated by a majority
  of  the Executive  Committee,  such designation  to be  made at  least four
  weeks  prior  to the meeting.  Other  meetings  will be  via  BITNET  or in
  person,  as required.  The Executive Committee will choose its own officers
  annually.

  Executive  Committee  members  are  normally  elected  to three  year terms
  beginning  on  January  1.  In order  to  ensure  continuity,  the  current
  Executive Committee,  functioning  prior to  ratification  of this Charter,
  will choose  four  of its  members by  lot to  have their  terms  expire on
  December 31, 1986,  four to  expire on  December 31,  1987,  and  three  to
  expire on December 31, 1988.

  The  electorate  for  the  Executive   Committee  and  those  eligible  for
  election  comprise  the Institutional  BITNET Directors  of the Class A and
  Class  B members.  Elections  are held in November of each year as follows:

  o   The Executive  Committee will  nominate at  least two persons  for each
      vacancy  and communicate  same to the  electorate, while simultaneously
      soliciting  additional nominations  supported by at least ten petitions
      from the electorate.

  o   Three weeks will be allowed for petitions.

  o   At the conclusion of the petition period, ballots  will be distributed,
      to be returned within three weeks.
1

                                                                       Page 4


  o   For  an election  with N vacancies,  the N highest vote-getters will be
      declared elected.

  o   Any  mid-term  vacancies  will  be filled  at the next annual election.
      Interim appointments may be made by the Executive Committee.

  o   An  individual  elected  to the  Executive  Committee may  continue  to
      serve  as long as  she/he remains  an Institutional  BITNET Director at
      any institution.

  Membership Fees

  The  Executive  Committee  has responsibility  for establishing  membership
  fees  as required  to maintain  stable  electronic  communication  services
  with a high degree of academic connectivity.

  Other Networks

  The  Executive Committee  will maintain  liaison with other networks having
  similar purposes, as required to extend BITNET connectivity worldwide.

  BITNET Services

  The  Executive  Committee  may enter  into an  agreement  with  a  suitable
  entity capable of providing BITNET management, fiscal, and legal services.

  Ratification and Amendment

  This  charter will  be ratified  upon affirmative vote of a simple majority
  of the  existing BITNET  Directors who return ballots in a special election
  for this purpose.

  After  ratification,  this charter may be amended upon initiation by either
  the Executive Committee or  petition  presented by 20% of the Institutional
  BITNET Directors,  and affirmative  vote of two-thirds of the Institutional
  BITNET Directors who return ballots.


   *************************************************************************
  * Announcing COMSERVE             by Timothy Stephen & Teresa M. Harrison *
  ***************************************************************************

  Comserve  is a  resource  for   students  and  professionals  interested in
  the study of human communication.  It  is a free information  service  that
  you  can  use  to  obtain   materials  to assist your teaching and research
  activities.  You can also use  Comserve to locate information about  people
  in  the  profession,  to  share   your own work, to  request information or
  resources from others,  or to   advertise  your  department's  programs  of
  study.
1

                                                                       Page 5


  Comserve  is  an  interactive   computer  program  that can  intercept  and
  interpret  commands  sent   to  it  over  BITNET.  It is capable of reading
  electronic mail that it  receives and acting on  commands it finds  in  the
  text  of the mail message.  Comserve can also  respond conversationally for
  users whose computers have this capability.

  Comserve  maintains  a  growing   collection  of  bibliographies,  research
  instruments,    announcements    of   professional   meetings   and   grant
  opportunities,  syllabi,  class    exercises,  job announcements, and other
  resources of  relevance to the field  of  communication   studies,  broadly
  defined.   Comserve also manages an electronic phone book  -- much like the
  SCA  Directory -- that you can use to locate information  about  others  in
  the discipline.

  You  can  command   Comserve   to  tell  you   about   its   collection  of
  resources,  to   send  you  a  copy  of  a  particular  file (bibliography,
  syllabus, etc),  to add information about yourself to  the phone  book,  or
  to  search  the   phone  book  for information about  others. In the normal
  case, Comserve respond to your  commands  within  an  interval ranging from
  about 5 seconds to a maximum of about 20 minutes.

  You  can   also   use   Comserve   as  a   means   for   advertising   your
  department,   yourself,  or  the  conference you are planning,  for posting
  questionnaires  that other users can obtain from Comserve  and  return   to
  you electronically, or for sharing your learning resources.

  You  can  start using  Comserve now  by  sending  mail   or  conversational
  commands   to  COMSERVE@RPICICGE.  Users of  IBM VM/SP (CMS) systems should
  send Comserve the command:

          SEND EASYCOM EXEC

  to  obtain an interface program that can be used to   simplify  interaction
  with  Comserve. (After you receive the program, simply type: EASYCOM.)

  Printed  copies   of  Comserve's   documentation   can   be   obtained   by
  sending   a  request  to  either STEPHEN@RPICICGE or  HARRISON@RPICICGE. An
  electronic  version of the documentation will be available   from  Comserve
  soon.

  The  range  of  commands   available   to  Comserve   users  is   different
  depending   on whether Comserve is being used conversationally  or commands
  are sent  as  mail   messages.  Currently,  Comserve  will   recognize  the
  following conversational commands:

          COMMAND                  ACTION

          ADDME       Add yourself to the user directory
          DELETEME    Delete yourself from the user directory
          DIRECTORY   Get lists of available files
          FEEDBACK    Send us your comments


1

                                                                       Page 6


          FORTUNE     Read a fortune cookie
          GOODBYE     Say goodbye to Comserve
          HELLO       Say hello to Comserve
          HELP        Get help on using Comserve
          NEWS        Read the latest news file
          NEWFILES    Find out if new files have been added
          PREVIEW     Preview a file before requesting it
          SEARCH      Search the user directory
          SEND        Obtain your own copy of one of Comserve's files

  Specific  methods  for  sending  conversational  messages   over BITNET are
  different   on  different  computers.  Most   IBM  VM/SP  (CMS)   computers
  accomplish this with the "TELL" command.  For example:

          TELL COMSERVE AT RPICICGE HELP

  sends  the   Help  command  to  Comserve.   Many  VAX/VMS  systems  use the
  "SEND/REMOTE" command to accomplish the same function. For example:

          SEND/REMOTE RPICICGE COMSERVE "HELP"

  Users   accessing  Comserve  through  electronic  mail  may  issue  any  of
  the following commands:

          COMMAND

          ADDME
          DELETEME
          DIRECTORY
          FORTUNE
          HELP
          NEWS
          NEWFILES
          SEARCH
          SEND

  Simply  place  the  command in an electronic note and address  the  note to
  COMSERVE@RPICICGE.

  Comserve  is   offered    through   the   cooperation  of  the  Center  for
  Interactive  Computer  Graphics and the Department of Language, Literature,
  and Communication -- both at   Rensselaer   Polytechnic  Institute.  It  is
  sponsored  by the Eastern Communication  Association  and has been endorsed
  by the Committee for Computer Applications and the  Legislative  Council of
  the Speech Communication Association.
1

                                                                       Page 7


   *************************************************************************
  * New Mailing Lists                                                       *
  ***************************************************************************

  INFO-FINITE@ARDEC.ARPA

  Info-finite is a mailing list for the discussion of problems, solutions and
  theory in finite element software.

  All requests to be added to or deleted from this list, problems, questions,
  etc., should be addressed to info-finite-request@ARDEC.ARPA.

  Coordinator: Ken Van Camp 


  NL-KR@ROCHESTER.ARPA

  NL-KR is  open to discussion  of any topic  related to the natural language
  (both understanding and generation) and  knowledge  representation, both as
  subfields of AI.  The Moderator's interests are primarily in:

      Knowledge Representation    Natural Language Understanding
      Discourse Understanding     Philosophy of Language
      Plan Recognition            Computational Linguistics

  Contributions are also welcome on topics such as:

      Cognitive Psychology (as related to NL/KR)
      Human Perception (same)
      Linguistics
      Machine Translation
      Computer and Information Science
      Logic Programming (same)

  Contributions may be anything from tutorials to speculation. In particular,
  the following are sought:

      Abstracts                             Reviews
      Lab Descriptions                      Research Overviews
      Work Planned or in Progress           Half-Baked Ideas
      Conference Announcements              Conference Reports
      Bibliographies                        History of NL/KR
      Puzzles and Unsolved Problems         Anecdotes, Jokes, and Poems
      Queries and Requests                  Address Changes (Bindings)

  This list is in some sense a spin-off of the AIList, and as such, a certain
  amount of overlap is expected. The primary concentration of this  list will
  be NL and KR,  that is,  natural language (be it understanding, generation,
  recognition,  parsing,  semantics,  pragmatics,  etc.) and  how  we  should
  represent  knowledge (aquisition,  access, completeness, etc. are all valid
  issues).  Topics deemed to be outside  the general scope of this  list will
  be forwarded to AIList (or other more appropriate list) or rejected.
1

                                                                       Page 8


  All requests to be added to or deleted from this list, problems, questions,
  etc., should be sent to NL-KR-REQUEST@ROCHESTER.ARPA.


  DESKTOP-PUBLISHING 

  Discussion group  for sharing information  on desktop publishing techniques
  and new technologies used in small publishing projects.

  All requests to be added to or deleted from this list, problems, questions,
  etc., should be sent to dtp-request%plaid@SUN.COM.

  Coordinator: Chuq Von Rospach 


  GAMEMASTERS@RINSO.LCS.MIT.EDU
  GAMEMASTERS%RINSO@XX.LCS.MIT.EDU

  Mailing  list to  serve  as  a forum  for the  discussion of adventure game
  programming, including questions  such as player  interfaces,  multi-player
  possibilities, text vs. graphics games, etc.

  All requests to be added to or deleted from this list, problems, questions,
  etcetera,   should  be  sent to   GAMEMASTERS-REQUEST@RINSO.LCS.MIT.EDU  or
  GAMEMASTERS-REQUEST%RINSO@XX.LCS.MIT.EDU.

  Coordinator: Brad Sagarin 
                            


  MUSIC-RESEARCH%PRG.OXFORD.AC.UK@CS.UCL.AC.UK

  The Music-Research  electronic  mail  redistribution  list was  established
  after a suggestion made at a meeting in Oxford in July 1986,  to provide an
  effective and fast means of bringing together musicologists, music analysts
  computer  scientists,  and others  working on  applications of computers in
  music research.  Initially, the list was established for people whose chief
  interests concern computers and their applications to

      - music representation systems
      - information retrieval systems for musical scores
      - music printing
      - music analysis
      - musicology and ethnomusicology
      - tertiary music education
      - databases of musical information

  The  following areas  are not the principal  concern of this list, although
  overlapping subjects may well be interesting:

      - primary and secondary education
      - sound generation techniques
      - composition
1

                                                                       Page 9


  All requests to be added to or deleted from this list, problems, questions,
  should be sent to music-research-request%prg.oxford.ac.uk@CS.UCL.AC.UK

  Coordinator: Stephen Page 


  WRITERS%PLAID@SUN.COM

  Mailing  list for science  fiction writers, both published and unpublished.
  This  list was created for authors to exchange and critique stories, and to
  hold discussions on any subject pertaining to writing science fiction.

  All requests to be added to or deleted from this list, problems, questions,
  etc., should be sent to the Coordinator.

  Coordinator: Chuq Von Rospach 



   *************************************************************************
  *  The Hewlett Packard Public Networking Newsletter                       *
  ***************************************************************************

  Last  month  we announced the  publication of a new electronic magazine for
  Digital  Equipment VAX users  (the VAX Toolbox),  so this  month the HP3000
  users  get their say.  Yes,  it's the  Hewlett  Packard  Public  Networking
  Newsletter.  A  little information,  courtesy of  the editor of HPPNN, Jeff
  Kell:

    ***********************************************************************
    ***   The Hewlett Packard Public Networking Networking Newsletter   ***
    ***********************************************************************

    Greetings all; we are still a small group but I expect it to grow a bit
    as time goes by, and we have some still locked into land mail.  Most of
    you initially  replied to the July Education column in _Interact_ and I
    think I responded to everyone's inquiry personally with a quick update,
    but for those who may have missed, let me give some quick background.

    The University of Tennessee at Chattanooga operates five HP-3000 CPU's
    and one IBM-4381 which is presently on Bitnet.  Three of the five HP's
    are  presently linked to  UT-Knoxville's MVS system via MRJE; but bear
    in mind  that the MVS system is NOT Bitnet addressable and is used for
    primarily  batch and  IMS activity.  The first  hope for a Bitnet link
    was the HP announcement of MRJE support for RSCS, recently released on
    the MPE-V/E 'T-Mit' product tape.

    The  information  presented  in the July column actually took place in
    April; the delay in publication of regular column features in Interact
    is three months.  It is a rather poor forum to conduct news on such an
    exploratory  project.  In June  we succeeded in connecting the HP with
1

                                                                   Page 10


    Bitnet, and  have already begun  several software projects to complete
    the  connection.  There are still quite a few problems to be resolved,
    but it does look promising. I will try to present our findings to date
    along with unresolved problems and currently addressed solutions.

    The Bitnet  link to the HP is rather limited.  HP seemingly 'added on'
    RSCS support  when in  fact the  link  will  function  to  some degree
    without  the much renowned RSCS support.  MRJE acts like a single user
    station with  a  single  console,  reader,  printer, and punch.  RSCS,
    accordingly,  treats  the HP  as though  it were  a single  user work-
    station. In concept, this is a poor basis for trying to do networking;
    but it will suffice with proper additional software.

    MRJE's RSCS  'support' amounts to little more than a kludgy way to get
    print files onto their  proper forms on the HP; it is very oriented to
    the  printer.  The  punch has little or no additional support.  Again,
    this is exactly the opposite of a primarily networking  function.  But
    again,  it is  functional.  This  should be  enough background  on the
    general problem at hand; neither side's software is really oriented to
    to networking at all - it is designed to feed print stations.

  ***************************************************************************

  Editor's  note:  That  was  a  brief  excerpt  from the  first  issue.   To
  subscribe to  Hewlett  Packard Public  Networking  Newsletter,  send a mail
  request to Jeff Kell, JEFF@UTCVM.


   *************************************************************************
  * CYBSERV                                                  by Bill Wilder *
  ***************************************************************************

  A mail  based  file server  has been established at address CYBSERV@ACADIA.
  This server will store files of particular interest to Cyber sites.  To use
  the  file server  send RFC822 mail to the address above (a subject line, if
  present, will  be  ignored).  Each  line of the message may be a command to
  the file server.  The following commands are available:

  HELP
       Return help information about this file server.

  DIR
       Provide a directory of files maintained by the server.

  GET    filename type Ã•setÃ¥
  SEND   filename type Ã•setÃ¥
  SENDME filename type Ã•setÃ¥
1

                                                                      Page 11


       Return by mail the specified file where "filename" is the  name of the
       desired file (1-7 characters),  and  "type" is the  type of  the  file
       (also 1-7 characters).  For some files it may be necessary  to specify
       "set" (yes, 1-7 characters).  The directory  listing for CYBSERV  will
       indicate whether a set must be specified.


   *************************************************************************
  * Coming soon: GRAND                                        by Judy Molka *
  ***************************************************************************

  City  University of New York  has been developing conferencing capabilities
  for  BITNET  under  the  terms  of  a  jointly  defined  effort  with  IBM.
  GRAND,  the conferencing system, and its associated user-interface programs
  CONVEY (aka CONFER) and GRAIL (for line-by-line terminals), are designed to
  operate  in a  distributed  fashion over an RSCS network.  Users sign on to
  local  or  'near-by' remote  GRAND  servers  which are  interconnected, and
  coordination  and  distribution of the various conference ('topic' in GRAND
  parlanc)  entries.  Zones of  influence (a la RELAY) can be built into each
  system to 'force' users on to the appropriate GRAND server.

  A  set of a  dozen GRAND  pilot  servers will soon be operational.  Besides
  providing  distributed conferencing, other applications are being developed
  which  will provide the  ability to distribute packages, with subscriptions
  lists for updates and bug reports.  GRAND is currently being used to shadow
  a number  of ARPANET  mailing lists and could be used to reduce much of the
  current gateway traffic due to ARPA mailing list subscriptions.

  GRAND provides  much of the same functionality in terms of reducing network
  load.  It will  soon  be  used  to  shadow  several  discussion  groups  on
  LISTSERV@BITNIC.  GRAND  also  provides an  explicit  segregation of  group
  messages from  personal  messages.  GRAND  promises lots  of functionality,
  but for non-VM  users will require some  user interface tools to be as easy
  as mail to use.


   *************************************************************************
  * More Revised LISTSERVs                                                  *
  ***************************************************************************

  LISTSERV@UGA - University of Georgia

  Harold C. Pritchett

  The  University  of Georgia is now operating a LISTSERV machine  using Eric
  Thomas' version of LISTSERV.  The main service  currently  being offered is
  a re-transmittal of most of the popular  distributions from  BITNIC.  Since
  UGA is  located  to the West  of the BITNIC-CUNYVM-PSUVM-OHSTVMA  backbone,
  any site  located west of  OHSTVMA can,  by deleting their  subscription to
  one  of the  supported  BITNIC lists  and subscribing  to the  same list at
  UGA, reduce the file load across these already overloaded links.
1

                                                                      Page 12


  Since  the  BITNIC  list  server  does   not  support  Peer   linking,  all
  submissions will  still have to be sent to the master list at BITNIC.

  Several  other lists  are supported,  and where the  other listserv is also
  running  Eric's code, they are linked as peers and mail sent to either node
  will be sent to all subscribers at all nodes.

  Below is a list of the lists currently being supported on the UGA listserv:

  List Name  Send To  Description
  ---------  -------  ----------------------------------------------
  APPLICAT   BITNIC   Applications under BITNET
  CYBER-L    BITNIC   CDC computer discussion list
  FUTURE-L   BITNIC   Future Developments in BITNET
  GGUIDE     BITNIC   BITNET Guide creation discussion
  IBM-NETS   BITNIC   IBM Networking discussion
  IBM7171    Note 1   Protocol Converters
  LIAISON    BITNIC   BITNIC Liaison
  LINKFAIL   BITNIC   Scheduled outage announcements
  MAIL-L     BITNIC   Mail transfer agents and Mail user agents
  MON-L      BITNIC   Monitoring and controlling BITNET use
  MUG        Note 2   Discussion of MUSIC/SP operating system
  RSCSV2-L   BITNIC   RSCS Version 2 discussion group
  S-COMPUT   Note 1   Super Computer discussion group
  STD-L      BITNIC   Standard Environments discussion
  TRANS-L    BITNIC   File Transport discussion
  UG-L       BITNIC   Usage guidelines discussion
  USRDIR-L   BITNIC   User Directory discussion
  VMPROB-L   UGA      Discussion of VM/PROBE monitor from UTCVM
  X400-L     BITNIC   X.400 Protocol for BITNET discussion

  Note1 - This list is  Peer linked  to a list  at Tulane University (TCSVM).
          Mail sent to  either  list is  distributed to the members  of both.
          You should send to the closest site.

  Note2 - This  list is  Peer  linked to a  list at Marist College  (MARIST).
          Mail sent  to either list  is distributed to the  members  of both.
          You should send to the closest site.

  The Revised  LISTSERVs support remote registration. To sign  up for  any of
  these  lists,  from a  site which  supports  messages,  send a  message  to
  LISTSERV at UGA with the following text:

     SUBSCRIBE LISTNAME Your Name

  From  a site which  does not support messages, send RFC822 mail to LISTSERV
  at UGA with the following as the first non-blank line of the text:

     SUBSCRIBE LISTNAME Your Name
1

                                                                      Page 13


  For more  information on LISTSERV, use one of the above methods to send the
  command HELP.  For  a copy of  the LISTSERV  users guide,  send the command
  INFO.

  ***************************************************************************

  Distribution lists from LISTSERV at CMUCCVMA

  MD40  Computer Club Information
  MD41  IBM CC Internal
  MD42  The VAX Toolbox Ã•A BITNET Magazine for VAX usersÃ¥
  MD43  XYZZY Distribution
  MD44  XYZZY Discussion
  MD47  Computer Club Members


  Distribution lists from LISTSERV at EB0UB011

  ASM370    - ASM370 Forum
  CHAT-L    - Distribution list for the Chat program
  CIUB-L    - Llista Interna del CIUB
  EARNTECH  - EARNTECH List
  INFOIBMP  - Info-IBMPC Digest
  LINGUA    - Programming Languages Digest
  LINKFAIL  - LINKFAIL Distribution List
  LSTSRV-L  - The Revised LISTSERV Distribution List
  MAILBOOK  - MAIL/MAILBOOK subscription list
  OPSYS     - Operating Systems Digest
  REXXLIST  - REXX Digest
  RSCSMODS  - RSCS modifications list



   *************************************************************************
  * The RELAY Rules                                                         *
  ***************************************************************************

  General Guidelines for Relay Usage                          8/04/86 (DRAFT)

  RELAY  provides real-time  communication between  multiple users at various
  institutions  in the BITNET,  EARN, and  NetNorth  networks.  Use  of these
  networks   for  any  purposes   not  directly   related  to  the  research,
  instructional,  and/or  administrative  tasks  for  which  your userid  has
  been authorized  by your  institution  may  result  in the  termination  of
  your ability to use the Relay.

  Depending  on the  network-access  policies of  your  institution  and  the
  usage  policies  of the  network  in which your  institution  resides, such
  unauthorized  use of these  networks  may,  alternatively,  result  in  the
  termination  of your  userid or  its  ability  to  communicate  over  these
  networks for ANY purpose.
1

                                                                      Page 14


  INTERNAL use,  using and/or  limiting the  Relay  conferencing  system  for
  communication  either  wholly  within  one node,  or within one institution
  over  several  nodes  and/or  servers, is  the total responsibility of that
  institution.

  NETWORK-WIDE  use, using  one or  more  Relay  servers to  communicate with
  another  Relay   server(s)  at  another  institution(s),  falls  under  the
  established  guidelines  presented  herein.   Failure  to  adhere to  these
  guidelines,  or where  general  network  usage  guidelines  may  have  been
  violated  may  result  in the  loss of  your ability to use Relay; or where
  such  actions  are not  administered  by the  local  host  institution  may
  result in expulsion of that server from the authorized sitelist.

  ***************************************************************************

  Background Information and User Responsibilities          9/02/86   (DRAFT)

  Relay  is a distributed  message server  which, by selective  switching and
  redistribution  of messages,  provides real-time  conferencing capabilities
  while  minimizing the  overhead on the  network links.  Since the potential
  load of uncontrolled  message traffic  on the  network can  affect transfer
  of files, stringent  controls over  Relay use  are mandatory.  Most control
  measures  are enforced  by Relay  automatically, but  some are  necessarily
  the responsibility of the user.  These include:

  o    Each  Relay  server  provides  service  to a  specific  collection  of
       one or  more  nodes  designated as  a "service  area".   To  determine
       which Relay server(s) you may use, issue the following command:

       In BITNET  :   TELL RELAY AT BITNIC /SERVERS
       In EARN    :   TELL RELAY AT DEARN /SERVERS
       In NetNorth:   TELL RELAY AT CANADA01 /SERVERS

  o    Excessive  queries,  channel  changes,  and other commands  which must
       be  processed by  Relay generate  considerable  overhead in some cases
       and  should be kept  to a  reasonable number.  In addition, you should
       direct your queries to only your assigned Relay(s).

  o    File  backlogs,  Relay host  CPU saturation,  link  failures, and node
       downtime  may make  Relay  temporarily  unavailable or restricted.  In
       such  instances you  should wait  until your Relay is available; it is
       not  proper to  redirect  signons  or Relay  links in such cases where
       the  alternate  path will  generate a  greater network  load  than the
       primary path.

  o    Proper  and  considerate  behavior  should be  observed  at all times.
       Misuses in this category include, but are not limited to:

       a. Disguising  your  identity  in a  /SIGNUP  by not  specifying  your
          full name, or by specifying someone else's name.
       b. Transmitting rude or obscene language.
1

                                                                      Page 15


       c. Channel  scanning;  attempting  to locate a private channel without
          first obtaining an invitation from a user on that channel.
       d. Annoying  other  Relay   users  by  transmitting  excessive  and/or
          repetitive messages (including the use of 'picture' EXECs).
       e. Failing  to  cease an  activity in  response to a  request to do so
          from  any  individual  designated  as the  'Relay  Operator'  for a
          Relay server.

  Repeated  violations  of the  above  may result  in the termination of your
  ability to use the Relay.

  ***************************************************************************

  Relay User Classification System                            9/09/86 (DRAFT)

  Due  to previously  high  volumes of  message traffic and the popularity of
  the  use of Relay  for casual  conversation,  users will be classified into
  one of two distinct classes:

  (1) Public user  class.  Any  user may  obtain public  access to Relay by a
      standard  /SIGNUP  command.  Public  users are  limited  to the  public
      channels  0-999 and  are additionally  subject to  channel limits, peak
      period  shutdowns,  and limited  hours of  operation.  In  general, the
      prime  time  period  (8:00 AM - 6:00 PM  local  time of  the host) will
      be closed to the public.

  (2) General user  class.  A  user may,  in certain  circumstances, be given
      the  general  user  class for  full access to Relay.  General users are
      restricted  to only  academic  conferencing  activities.   Abuse of the
      general  class will  result in  the loss of  general  user  priviledge.
      General user class is usually restricted to faculty/staff/grads.

  General  user class  can only be  granted by  the host Relay contact or his
  designate.  Users  from other  institutions  must submit  adequate evidence
  of  authorization  to request  general classification, usually by a request
  from  the listed  administrator  or contact  from  the user's  institution.
  The host  Relay contact  (or designate)  may require additional information
  or place further constraints on such services.

  ***************************************************************************

  Corrective Actions -- Relay Operator Responsibilities     8/21/86   (DRAFT)

  The day-to-day  maintenance  and operation of a Relay server is carried out
  by the  "Relay Operator", an  individual  or group  of individuals  who are
  responsible  to the  institution's  network  administrative authority.  The
  Relay  Operator is  also responsible  for implementing corrective action to
  temporarily  or permanently  terminate  a user's  access  to the  Relay  in
  cases  of  violation of  the guidelines described in other sections of this
  document.
1

                                                                      Page 16


  Actions  that can be  taken by any  Relay Operator  against offending users
  of any and all Relay servers:

     * sending an offending user a warning notification by message or mail
     * forcing the offending user from the current Relay session
     * temporary lockout (2 days or less) of the offending user

  Actions  that  can be  taken  only by the  Relay Operator  of the offending
  user's Relay server:

     * temporary lockout (over 2 days) of the offending user
     * permanent lockout of the offending user from Relay use

  Any  corrective  action taken by a Relay Operator against an offending user
  of another  institution's  Relay server,  other than single instances of an
  abusive  user being  forced  as a  warning, should be documented by sending
  mail to that server's Relay Operator outlining the reason for the action.


   *************************************************************************
  * Feedback                                                                *
  ***************************************************************************

  Date:         Sun, 17 Aug 86 09:25:32 IST
  From:         Zvika Bar-Deroma 
  Subject:      Netmonth AUG1986
  To:           Chris Condon 

  Hi Chris,

  I  haven't  read  it yet,  but  "hallelujah  for  the  contents  part +  CC
  characters  "a la VM/COM "  ( hope  it's as intersting as aesthetical....).

                  Keep up the good work,

                                    Zvika

  ***************************************************************************

  Date: 18 August 1986, 09:23:54 CDT
  From: X075ZH   at TAMVM1
  To:   BITLIB at YALEVMX

  Chris;

  I also  want to  say that  I do enjoy the new NetMonth format and find it a
  lot better  than the old format.I found the article by Jeff Kell to be very
  informative  and  useful  and I  am sure  it will  be  passed  on to  other
1

                                                                      Page 17


  users  who could  use  some of  the information  in it. Thanks for the very
  informative guide that you put out each month and keep up the good work.

                      Take care;

                      Richard Lee Holbert

  ***************************************************************************

  Date:     Mon, 18 Aug 86  13:39:49 ADT
  From:     wdw@Acadia  (Bill Wilder)
  To:       bitlib@yalevmx

  Chris,

  One  problem I  have  in using  file servers, and perhaps  others have this
  problem  as well,  is that  I am  not  at an  IBM  site  and  I cannot send
  interactive  messages.  I can  send  RFC822  mail,  and I can punch NETDATA
  format  requests  to nodes.  Would  you be  able to  explain to those of us
  in  the  under-developed  world  (i.e.  non-IBM)  more   about  interactive
  messages,  IBM Notes,  IBM  Profs mail,  NETDATA format,  SENDFILE  format,
  class M punch etc.

  Thanks

  Bill Wilder - Acadia University

  >> Uh, oh.  You  found my weak  spot... technical questions.  I don't  know
  how  most of  those things work,  I just  USE 'em.  I  could explain to you
  what  an  interactive  message  IS,  but  why  it does  what  it does  is a
  mystery  to me!  Yes,  my major  is Computer  Science, but with an emphasis
  on  Information  Management (as  opposed to Scientific Computing where they
  learn  FORTRAN and  take lots  of Math  courses,  I  took COBOL and lots of
  Business courses).  That doesn't answer your question does it?  Oh well...


   *************************************************************************
  * NetMonth Policies                                                       *
  ***************************************************************************

  If  you have questions or comments about BITNET or NetMonth  that you would
  like printed here,  mail your letter to BITLIB@YALEVMX.  Make sure that you
  specify in the "Subject:"  header or somewhere in the letter that it is for
  the NetMonth  letters  column. This  doesn't mean that your  letter will be
  printed, but it helps.  Your opinion counts!

  Article Submissions:  The  only requirements for NetMonth articles are that
  they be informative,  interesting, and  deal with  BITNET  services (or any
  other  good BITNET  related topics).  The  editor  will  inform  you of any
  changes to your writing and will submit them  for your  approval, deadlines
  permitting.  Send your articles to BITLIB@YALEVMX.

  ---------------------------------------------------------------------------

  FuzzyBytes Electronic Publishing                      "Because We're Here."